RubyKaigi 2024
感想
以下の文章は、社内ブログに書いた文章から抜粋したものです。
RubyKaigi、Twitter とか #rubykaigi チャンネルでわちゃわちゃ書いてたように旅として楽しかったというのももちろんあるんですが、ちゃんと技術のイベントとして技術の話ができたのがやっぱり楽しかったです。 個人的には YJIT についての話を一番楽しみにしていて、YJIT のコアなアルゴリズムの生みの親である Maxime さんと直接お話できたのが一番テンションの上がった瞬間でした。 ウェブサービスの開発者としては「たくさんのリクエストを高速に捌いてユーザーさんのストレスを減らしたい」と思うことは多々ある訳ですが、その処理の多くをインタープリター方式で動く Ruby でやっているというのは、コンピューターサイエンスを専門にしていた自分にとっては未だに驚きがあります。実務的には Rails が成熟していて開発進めやすいとか、結局時間かかるのは DB クエリだから時間だけ見るとそれなりの割合でアプリ部分はボトルネックじゃないとかあるわけですが、やっぱ速くできるなら速くしたいじゃないですか。
で、その Ruby をここ数年劇的に速くしているのが YJIT です。
JIT コンパイルをやれば速くなるというのは理屈は分かるんですが、実際にやれて成果も出てるのはめちゃかっこいいですよね。Ruby 本体への貢献って色々な形があって、機能を増やしたとか、バグを直したとか、それぞれにそれぞれの良さがあります。そこにおいて YJIT というのは Ruby 3.3 では CRuby を使っている人ほぼすべてに恩恵を与えるような貢献と言ってよいほどに成長していて、これはもうすごくかっこいい姿に見える訳です。我々もいくつかのサービスでは YJIT の恩恵を受けているんですよ。Maxime さんの発表が終わったあと、壇上から降りてきた Maxime さんの周りに僕含め 3〜4 人が質問に集まっていて、その中のお一人が Maxime さんのことを "You're my hero." とおっしゃっていたのが印象に残っています。
YJIT は割と理解しやすい（気がする）のも面白い点だと考えています。JIT コンパイルは古くは Lisp とかの時代からあるもので、実用的には Java の JVM のやつとか Python の pypy とか JavaScript の V8 のやつとかが有名です。ただ個人的には、複雑めなアルゴリズムが詰まっていて難しいな〜という気持ちがありました。それでいうと、YJIT が使っている JIT コンパイルの仕組みは現状比較的シンプルな作りになっています。他の JIT コンパイラの実装をしっかり読んだことは無いですが、CRuby の JIT コンパイラの実装は探索しやすかったです（比較として OpenJDK の JIT コンパイラの実装を読むとか面白いかもなあ）。
たぶんここから YJIT の実装が簡単になることはありません。複雑になっていくのみです。k0kubun さんの発表で YJIT に最近入った最適化の説明があったように、ここからは色々な最適化を入れてより速くしていくのだろうなと予想しています。読むなら今！ そんな YJIT について自分が気になっていたのは、JIT コンパイラでの段階コンパイルです。JVM や V8 では、JIT コンパイラが 2 種類搭載されています。ひとつは立ち上がりが速いけど最適化はしないコンパイラ、もうひとつは最適化バリバリだけど重いコンパイラです。ふたつ用意しておいて最初は軽量な方を使い、後から要所要所で重い方を使うことで速度のバランスを取っています。これが段階コンパイルなどと言われるやつです。
YJIT によるコンパイルも段階的にする予定はあるんだろうか。これが最近自分の関心事でした。Maxime さん曰く、近々でそうするつもりはなく、それよりも C 拡張で JIT コンパイルができないことの方がボトルネックに見えるので先にそちらを手掛けているとのことでした。段階的にすると実装が複雑になってメンテしづらくもなりますしね。 いやーしかし、JIT コンパイルによって C 拡張が邪魔になるかもしれないとは、こちらもなかなか驚きです。素朴な感覚では Ruby で書くより C で書いた方が速そうじゃないですか。Ruby と C とを行ったり来たりする処理が挟まるので単純に Ruby と C との比較にならないのは分かるんですが……。未だに信じられていないので、もう少しベンチマーク結果を眺めてみようと考えているところです。
（後略）